Thanks!
There are a few issues with this patch.
Since it creates a new stream, more related validation logic similar to those in process_stream_frame() needed.

And after creating the stream, need to call lsquic_stream_window_update().

Thank you for your suggestions. The three points mentioned above are indeed necessary.
Below, I listed the processing flow required during creation of a stream in process_max_stream_data_frame() in accordance with the RFC specifications:

First Stage:
Points 1 to 3 are checks that need to be performed regardless of whether the stream exists.
Points 1 and 2 are exceptional cases, while point 3 is a normal case.

1. Check whether receiving this frame aligns with both the frame and stream semantics (RFC9000, Section 19.10: A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform a peer of the maximum amount of data that can be sent on a stream.)
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5861
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L6182

2. Check whether the stream complies with the HTTP/3 specification (RFC9114, Section 6.1: HTTP/3 does not use server-initiated bidirectional streams.)
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5868

3. Discard frame during connection closure
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5877

Second Stage:
If the stream does not exist, the following checks need to be performed in sequence: why the stream does not currently exist, and whether the stream can be created now.
Points 4 and 7 are normal cases, while points 5 and 6 are exceptional cases.

4. Check whether the stream has been previously released (RFC9000, Section 2.1: A QUIC endpoint MUST NOT reuse a stream ID within a connection.)
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5887

5. Check whether the stream is initiated by the local endpoint (RFC9000, Section 3.2: For bidirectional streams initiated by a peer, receipt of a MAX_STREAM_DATA or STOP_SENDING frame for the sending part of the stream also creates the receiving part. RFC9000, Section 19.10: Receiving a MAX_STREAM_DATA frame for a locally initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR.)
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5894

6. Check whether the Stream ID exceeds the current maximum limit (RFC9000, Section 19.11: This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^62-1. Receipt of a frame that permits opening of a stream larger than this limit MUST be treated as a connection error of type FRAME_ENCODING_ERROR.)
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5898

7. Check whether the HTTP/3 connection is in the closing phase (RFC9114, Section 7.2.6: The GOAWAY frame (type=0x07) is used to initiate graceful shutdown of an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint to stop accepting new requests or pushes while still finishing processing of previously received requests and pushes.)
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5906

Third Stage: After the stream is created, the following information needs to be updated and recorded:
8. HTTP/3 Frame (GOAWAY) (RFC9114, Section 7.2.6: In the server-to-client direction, it carries a QUIC stream ID for a client-initiated bidirectional stream encoded as a variable-length integer.)
https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L5933

9. QUIC Frame (MAX_STREAM_DATA): lsquic_stream_window_update (RFC9000, Section 19.10: A MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform a peer of the maximum amount of data that can be sent on a stream.)
   https://github.com/litespeedtech/lsquic/blob/master/src/liblsquic/lsquic_full_conn_ietf.c#L6191

We will spend some more time reviewing RFC9000 and RFC9114 to ensure there are no other issues, and we will submit a new commit once confirmed.